AWS PrivateLinkとAmazon VPC Latticeの関係性を整理してみた

AWS PrivateLinkとVPC Lattice、似てきたな

こんにちは、のんピ(@non____97)です。

皆さんはAWS PrivateLinkとVPC Lattice、似てきたなと思ったことはありますか? 私はあります。

アップデートでVPC Lattice が TCP 接続をサポートするようになりました。

https://dev.classmethod.jp/articles/amazon-vpc-lattice-tcp-vpc-resources/

「うお〜、良いじゃん」

となったに違いありません。

ここで気になるのはAWS PrivateLinkとの関係性です。

今回のアップデートにより、AWS PrivateLinkとVPC Latticeは以下の同じ特徴があります。

• 送信元と送信先のVPCのCIDR重複がOK
• 片方向リクエストのみ通信OK
• TCP接続をサポート

何だか似てきた今、どのような場面でどちらを使えば良いでしょうか。

また、アップデートによりAWS PrivateLinkはNLBを介さずにVPC内リソースにアクセスできるようになりました。

https://dev.classmethod.jp/articles/privatelink-vpc-endpoint-direct-access-update/

NLBを介さずに通信させる場合はResource Gateway(以降RGW)、Resource Configurationなるリソースの準備が必要です。こちらのリソースのARNを見てみると、VPC Latticeのものであることが分かります。

RGW、Resource Configuration、VPCエンドポイント、VPCエンドポイントサービスのARNをまとめると以下のとおりです。

リソース	ARN
Resource Configuration	arn:${Partition}:vpc-lattice:${Region}:${Account}:resourceconfiguration/${ResourceConfigurationId}
Resource Gateway	arn:${Partition}:vpc-lattice:${Region}:${Account}:resourcegateway/${ResourceGatewayId}
VPCエンドポイント	arn:${Partition}:ec2:${Region}:${Account}:vpc-endpoint/${VpcEndpointId}
VPCエンドポイントサービス	arn:${Partition}:ec2:${Region}:${Account}:vpc-endpoint-service/${VpcEndpointServiceId}

「AWS PrivateLinkの仕組みなのにVPC Latticeのリソース使うのか?」となりますよね。

2つの関係性に大きな動きがあったに違いありません。

と言うことで、AWS PrivateLinkとAmazon VPC Latticeの関係性を整理してみます。

いきなりまとめ

• AWS PrivateLinkとVPC Latticeが一部統合された
  • VPC LatticeがService Network型VPCエンドポイントを使用する際はAWS PrivateLinkの仕組みを用いて通信する
  • AWS PrivateLinkのResource型VPCエンドポイントを使用する際は、VPC LatticeのリソースであるResource GatewayとResource Configurationを使用する
• こんな時はAWS PrivateLinkを使おう
  • UDP通信が必要
  • 通信の検査をしたい
  • SaaSとして提供したい
  • 転送量が多い
• こんな時はVPC Latticeを使おう
  • 送信元に対してIAM認証をかけたい
  • ALBを挟まずにお手軽にLambda関数やECSサービスをターゲットとしたい
  • HTTP/1, HTTP/2, gRPCのログ出力をマネージドで行いたい
  • 転送量が少ない

AWS PrivateLinkとは

AWS PrivateLinkとVPC Latticeの関係性を整理する前に、それぞれの言葉の定義の確認が必要だと思います。

まずは、AWS PrivateLinkです。

私の理解ではAWS PrivateLinkは「接続先の各サービスもしくはリソースに対応したENIのVPCエンドポイントを介して、インターネットを経由せずにプライベートな通信を提供する仕組み」です。

AWS PrivateLinkは仕組みであってサービスではないのがポイントです。

「接続先の各サービスもしくはリソースに対応したENIのVPCエンドポイントを介して」について補足していきます。

AWS PrivateLinkで接続するにはVPCエンドポイントを用意する必要があります。

このVPCエンドポイントは接続先の各サービスおよびリソースごとに作成する必要があります。

一つのVPCエンドポイントから複数のサービスやリソースに対して接続できる代物ではありません。

AWS PrivateLinkのVPCエンドポイントは以下の4タイプがあります。

VPCエンドポイントのタイプ	特徴	料金
Interface型	任意のTCPまたはUDPのトラフィックを流すことができる	- 0.01 USD/AZ/VPCエンドポイント/h - 0.01 USD/GB
Gateway型	通信の中間コンポーネントに対してトラフィックを流すことができる	- 0.01 USD/AZ/VPCエンドポイント/h - 0.0035 USD/GB
Resource型	別VPCにあるリソースにトラフィックを流すことができる	- 0.02 USD/VPCエンドポイント/h - 0.0035 USD/GB
Service Network型	VPC LatticeのService Networkに紐づいているサービスにトラフィックを流すことができる	VPCエンドポイントに対しての課金はなし VPC Lattice Serviceとしての課金は発生

各タイプを図にすると以下のとおりです。

同じVPCエンドポイントでも微妙に料金が異なるのが注意すべきポイントですね。また、上述の料金にはNLBやクロスリージョン転送量、VPC Latticeに対する料金は含まれていないのでご注意ください。単純にVPCエンドポイントに対する料金のみ記載しています。

最新の料金については以下をご覧ください。

• AWS PrivateLink Pricing – AWS
• Simplified Application Networking – Amazon VPC Lattice Pricing – Amazon Web Services

VPCエンドポイントで接続できるサービスやリソースは以下5パターンです。

接続先	VPCエンドポイントのタイプ	利用場面
AWSサービス	- Interface型 - Gateway型	EC2やSSMなどのAWSサービスエンドポイントとのプライベート接続
PrivateLink Readyパートナーのサービス	- Interface型 - Gateway Load Balancer型	SaaSとのプライベート接続
AWS Marketplace 経由で購入したPrivateLink対応SaaS	- Interface型 - Gateway Load Balancer型	SaaSとのプライベート接続
NLBもしくはGWLBで公開しているサービス	- Interface型 - Gateway Load Balancer型	- SaaSとのプライベート接続 - セルフマネージドなサービスとの接続
リソース	- Resource型	Resource Configurationで設定されたリソースとの接続
VPC Lattice Service Network	- Service Network型	VPC LatticeのService Networkに紐づいているサービスとの接続

アップデートでリソースとVPC Lattice Service Networkが追加になっていますね。

ちなみに、「ENIのVPCエンドポイント」とした背景はGateway型VPCエンドポイント経由の通信はAWS PrivateLinkではないためです。

Gateway型VPCエンドポイントは、指定したVPC上にENIが生えてくるのではなく、VPCエンドポイントとVPCを関連付けるような形で実装されています。

Gateway型VPCエンドポイントがAWS PrivateLinkの仕組みを利用しないことはAWS公式ドキュメントで明に説明されています。

別のタイプの VPC エンドポイントである Gateway があり、これはゲートウェイ エンドポイントを作成してトラフィックを Amazon S3 または DynamoDB に送信します。ゲートウェイエンドポイントは、他のタイプの VPC エンドポイントとは異なり、AWS PrivateLink を使用しません。

AWS PrivateLink の概念 - Amazon Virtual Private Cloud

ゲートウェイ VPC エンドポイントは、VPC にインターネットゲートウェイや NAT デバイスを必要とせずに、Amazon S3 および DynamoDB への信頼性の高い接続を提供します。ゲートウェイエンドポイントは、他のタイプの VPC エンドポイントとは異なり、AWS PrivateLink を使用しません。

ゲートウェイエンドポイント - Amazon Virtual Private Cloud

VPC Latticeとは

私の理解ではVPC Latticeは「Service Networkを介して接続する、アプリケーションネットワーキングサービス」です。

Service Network型VPCエンドポイントもしくはService Network型VPC Associationを介して、接続をします。

従来はService Network型VPC Associationのみでした。こちらはServiceを束ねたService NetworkをVPCに関連づける形です。

今回のアップデートでService Network型VPCエンドポイントという接続方法が追加されました。

従来のService Network型VPC Associationは接続はルートテーブルの意識が不要だったりと簡単なのですが、以下のような注意点がありました。

• VPCに関連付けできるService Networkはひとつまで
• VPCと関連付けしているため、オンプレミスからは接続できない

Service Network型VPCエンドポイントによる接続はそれらの注意点が解消されています。

Service NetworkごとにService Network型VPCエンドポイントを作成すれば、複数Service Networkのアプリケーションに接続できますし、リンクローカルアドレスによる接続ではないので適切なルーティングをしてあげれば、オンプレミスからも接続できます。

AWS PrivateLinkとVPC Latticeの関係性の整理

AWS PrivateLinkとVPC Latticeの言葉の定義が終わったところで、関係性の整理をします。

一言で言うと、AWS PrivateLinkとVPC Latticeが一部統合されました。

どこが統合されたのかというと、Service Network型VPCエンドポイントとResource型VPCエンドポイントによる接続部分です。

接続方法カットと接続時のリソースカットで見ていくと分かりやすいです。

まずは接続方法カットです。

Service Network型VPCエンドポイントを作成しようとすると、サービスネットワークエンドポイントを使用して VPC Lattice サービスネットワークに接続します。AWS PrivateLink を使用しますと説明文が表示されます。

このことからService Network型VPCエンドポイントを介した通信はVPC Latticeのリソースを介してAWS PrivateLinkの仕組みを利用していることが分かります。

図示すると、以下のとおりです。

また、接続に使用するリソースカットで見ると、ARN上はVPC LatticeのリソースであるResource Gateway、Resource Configuration、Service NetworkはAWS PrivateLinkで用いられていることが分かります。

このようにAWS PrivateLinkとVPC Latticeの一部は統合されています。

一部が統合された影響か、マネジメントコンソールのメニューを見ると、PrivateLink and LatticeとAWS Private LinkとVPC Latticeがまとめられていました。

AWS PrivateLinkとVPC Latticeの差異

AWS PrivateLinkとVPC Latticeのどちらもできること

AWS PrivateLinkとVPC Latticeの関係性が何となく分かったところで、差異についても確認しましょう。
※ 一部統合されている今、差異と表現しづらい and 仕組みとサービスを比較するようなものなので評価軸として適していないような気もしている

まずはAWS PrivateLinkとVPC Latticeのどちらもできることについての確認です。

AWS PrivateLinkとVPC Latticeのどちらもできることは以下のとおりです。

• 送信元ネットワークのCIDRと送信先ネットワークのCIDRが同一の場合の通信
• TCP通信
• 送信元がオンプレミスの場合の通信 (Service Network型VPC Associationを除く)
• 送信元と送信先のAWSアカウントが異なる場合の通信
• リソースベースポリシーによる制御

AWS PrivateLinkでのみできること

AWS PrivateLinkでのみできることは以下のとおりです。

• UDP通信 (Resource型VPCエンドポイントおよびService Network型VPCエンドポイントは除く)
• 通信の中間コンポーネントとして動作させる (Gateway Load Balancer型VPCエンドポイントのみ)
• SaaSとしてのサービス提供 (Resource型VPCエンドポイントおよびService Network型VPCエンドポイントは除く)
• 最大100Gbps/AZまでスケール
  • VPC Latticeの場合は10Gbps/AZまでスケール

UDP通信が必要であったり、SaaSとしてサービス提供するのであればAWS PrivateLinkの利用一択になります。

また、「できること」という観点ではないのですが、転送料金はAWS PrivateLinkの方がVPC Latticeよりも安いです。そのため、ある程度の転送量がかかる場合はAWS PrivateLinkの仕組みで接続すると良いでしょう。

https://dev.classmethod.jp/articles/lattice_privatelink_cost/

VPC Latticeでのみできること

VPC Latticeでのみできることは以下のとおりです。

• HTTP/1, HTTP/2, gRPCのログ出力をサービスとして実施
  • TLSのログ出力はAWS PrivateLink × NLBで可能
• ルートテーブルの自動設定 (Service Network型VPC Associationのみ)
• IAM認証
• ALBを介さずにターゲットにLambda関数を指定
• ALBを介さずにターゲットにECSサービスを指定
• ターゲット間のトラフィックの重み付け
  • AWS PrivateLinkの場合はターゲットとして設定するALBのリスナールールで実施
• 同時接続数上限なし
  • AWS PrivateLinkはIPアドレスとポートの組み合わせに対して55,000の同時接続または1分あたり55,000の接続

マイクロサービス間の接続でいうと、VPC Latticeの方が足回りのコントロールがしやすそうですね。

L3の知識もAWS PrivateLinkと比べるとそこまで求められないため、スピード感が求められる場合はVPC Latticeの方が楽かもしれないです。

なお、料金的に個人的にはVPC LatticeでTCP接続する旨みはあまり感じていません。

TCP接続に必要なService NetworkにVPCリソースを追加にかかる料金は 0.10USD/h です。1リソース接続するのに毎月73USDほどかかるのはネックかなと思います。

一方で1つのVPCエンドポイントからService Network内の複数のVPCリソースに接続できるようになるので、Consumer側としては大量のVPCエンドポイントを作成する必要がなく、VPCエンドポイントの料金を抑えることが可能です。

AWS PrivateLinkとVPC Latticeのどちらもできないこと

AWS PrivateLinkとVPC Latticeのどちらもできないことは以下のとおりです。

• ConsumerとProviderで双方向にリクエストを投げ合う

ConsumerとProviderという関係性なので、しょうがないと言えばしょうがないです。

AWS PrivateLinkとAmazon VPC Latticeが一部統合されました

AWS PrivateLinkとAmazon VPC Latticeの関係性を整理してみました。

関係性としては、AWS PrivateLinkとAmazon VPC Latticeが一部統合されています。

ただ、統合されていない部分もある訳で使い分けは未だに必要です。整理しながら使いこなしましょう。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!